正しいものを正しくつくる プロダクトをつくるとはどういうことなのか、あるいはアジャイルのその先について
著 : 市谷聡啓
https://m.media-amazon.com/images/I/41txD1eZGrL._SY291_BO1,204,203,200_QL40_ML2_.jpg
Amazon : https://amzn.to/3H1j8s9
本書で扱うテーマは 3 つ
1. アジャイルに作る : 作ることを通じて学びを得る
2. プロダクトとして何をつくるべきかを見定める方法
3. こうした問題を乗り越えた先にある境地
本書の対象者
プロダクトづくりに関与する全ての人
プロダクトチームをリードする立場
プロダクトチームを外から支援する組織マネジャー、プロダクトマネジャー
nobuoka.icon プロダクトマネジャーはプロダクトチームの外なのか？
プロダクトオーナーやプロダクトチームのメンバー
1 章 なぜプロダクトづくりがうまくいかないのか
プロダクト開発の技術も、プロセスもチームのあり方も進んでいる
少ないコードでできることが格段に増えている
アジャイル開発 (特にスクラム) も広まっている
関係者との距離感やコミュニケーションも変化
以前の形
発注者 (や事業の企画担当者)
プロジェクトマネジャーがコミュニケーションの入り口を務める
その後ろはチームリーダーが引き受ける
その先にシステムエンジニアがいて、さらにパートナーの開発会社メンバー
現在は、プロダクトに責任を持つ人と開発チームのメンバーが日々直接的なコミュニケーションを取っている
現在のプロダクト開発は、誰の頭の中にも正解がないものをつくっていく開発
プロダクトの不確実性を高めるのは多様性
プロダクトの多様性
SoR と SoE という分類があるように、求められることに違いがある
SoR では信頼性が重要なので、要件定義が大きくなる
それをつくる人たちの多様性
役割や経験、働き方
これまでは確実性を上げる方向だった
例えば要件定義
要求と要件と仕様の違い
技術の幅が広がったことで要件定義を顧客だけで行うことが難しくなり、ベンダー側がリードするように
確実性を上げるために : 要件定義をしっかりやり、合意を重視し、合意形成を変えられないものとする
現在では、それはムダや見せかけの合意形成になりがち → アジャイル開発
ひとつのフレームワークがスクラム
実践知の不足により現場が混乱し、失望へ
2 章 プロダクトをアジャイルにつくる
アジャイルの前に存在したもの
ケント・ベックのエクストリームプログラミング (XP)
ジム・ハイスミスの適応型ソフトウェア開発 (ASD)
ジェフ・サザーランドとケン・シュウェイバーのスクラム
アリー・バン・ベネカムの DSDM、FDD
これらの考え方ややり方の共通点や相違点を検討し、アジャイルという言葉が選択された
『アジャイルソフトウェア開発 (Cockburn)』 によると、不同意の同意があったという
詳細なやり方はそれぞれなので同意しないという同意
アジャイルソフトウェア開発宣言の 4 つの価値、アジャイル宣言の背後にある原則
スクラムについて
初めてアジャイル導入していく際にはゴールデンサークルを意識すると良い
Why : なぜアジャイルに作るのか？ (これは How 前提なので、より適切なのは、「自分たちのプロダクトづくりのありたい姿は？」)
アジャイルに作る 9 つの意義
How : (アジャイルに作っていくとしたら) どのようなアジャイル手法でやっていくのか
What : 具体的にやること。 型との diff から実際にやることを決める
3 章 不確実性への適応
アジャイルなプロダクトづくりの 2 つの課題
合意形成
基本の 4 つの期待 : QCDS
品質が最も捉えづらい
ISO/IEC 9126
デザインと学習についての期待
期待マネジメントしていく必要
反復的なプロダクトづくりのマネジメントには 2 つのレバー
リスクマネジメントと期待マネジメント
学びを通じて出てくる新たな作るべきものが計画づくりの難易度を高める
学びにより新たな要求が出てくる → 既存の要求とのトレードオフが発生
共通理解があればよいか、なければ期待違いが発生
ソフトウェアも変更に耐える構造である必要
基本はスケジュールと機能のトレードオフ
どちらも取りたい場合に予算の追加が検討されるが、ブルックスの法則の通り、予算を追加したらなんとかなるわけではない
人の期待をマネージしながら不確実性に適応する術
4 章 アジャイル開発は 2 度失敗する
2 つの壁
1. アジャイルな開発に移る際の様々な困難
2. プロダクトを作り終えた後に発生 : プロダクトが期待した成果に繋がらない
間違ったものを正しく作っている
プロダクトオーナーの重要性
プロダクトオーナーの職務
チームとプロダクトオーナーの間の 2 つの境界
プロダクトの実コードレベルで作るかどうかの違い
エンジニアリングへの理解の度合い
スクラムへの理解の度合い
アウトプットとアウトカムの境界
スクラムの枠組みの中にアウトカムに繋げるための仮説検証がないため、開発チームはアウトプットに責任を持ち、プロダクトオーナーがアウトカムに責任を持つ構図になりやすい
5 章 仮説検証型アジャイル開発
個々人の理解を外在化するためのツール : 仮説キャンバス
プロダクトの基準を個人が持つかチームで共有するか → 個人がボトルネックになりやすいので、チームで共有したい
本書はここから、プロダクトづくりの民主化がテーマになる
2 つの計画づくり
開発の計画づくり
検証の計画づくり : まずはビジョンを描き、ビジョン実現のためにわかっていないことを明らかにするための活動を計画する
アンチパターン
「わからないから」 でやることはアンチパターンに該当しやすい
まずはやる、とか
教科書通りやる、とか
検証は、最小限の活動で学びが最大となるように
仮説検証の前の状況調査 (エスノグラフィー)
プロダクトづくりでも、参与観察が可能ならそうすべき
正しくないものを理解し、そこから正しいものの輪郭を描く
正しくないものを作らないために
選択肢の幅を徐々に狭めていく → セットベース
選択には 3 段階
目的選択 (何のために必要か)
実体選択 (実現のために何が必要か)
数多の要求から最初に取り組むべきものの選択、必要な機能の定義
手段選択 (どうやって実現するか)
機能設計、UI 設計、データ構造の 3 つの観点で選択
補足 : リーン周りの整理
セットベースではじめて、MVP を特定していく (特定したらポイントベースに)
切り替わりタイミングが事業としての意思決定の節目
ソフトウェアを作らないとそれ以上検証できないというところ
この前段 (価値探索) と後段 (アジャイル開発) をあわせて本書では仮説検証型アジャイル開発と呼ぶ
6 章 ともにつくる
価値探索から正しく作るへの接続の 3 つの観点
プロダクトバックログ詳細化への段階設計
目安として 3 段階
機能仮説の段階
粗いが、コスト把握のためにやっておくべき
MVP を特定する段階
ユーザーストーリーマッピングを行って MVP 特定
スプリント開発前夜 (スプリントプランニングの段階)
プロダクトバックログに対する受け入れ条件をまとめる活動
仮説検証の精度と頻度の戦略
プロダクトの構想が固まる前は頻度高く、一通りの検証が終わったあとは精度を重視
わかったことを正しく作るという仮説検証型アジャイル開発 同調圧力や確証バイアスに負けないように
視座と視野を動かす
視座を動かす難しさ
上位の視座での経験がないから想像できない
自分で経験する以外には、その立場の人との対話を通じて考え方に触れること
人は目の前のことに集中してしまいがち
視座の切り替えは大体の人にとっては負荷が高い
多様性は不確実性を高めるが、不確実性に適応するにも多様性が必要
チームの理想は、ひとりの人間のように動くこと
共創の関係
#アジャイル #書籍